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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TR.A.NSACTIONS 

Cross-Reference to Related application 

This application is a continuation-in-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

Field of the Iwhntion 

This invention pertains in general to electronic commerce and in particular to a method 
and system for conducting electronic pa>aneni transactions via the Internet. 

Background of the Invention 

Electronic commerce conducted over the Internet has become increasingly imponant 
over the last decade. Online merchants offer goods and ser\aces for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
raav be delivered to the customer by allowing a download via the file transfer protocol 
('TTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic delivery. 

Typically, these goods and ser\aces are displayed on the merchant's web site and a 
prospective customer viev^^s, selects, and purchases the goods using web browsing software 
such as NETSCAPE NAVIGATOR*^. The customer usually pays for a product by establishing 
a secure connection with the merchant's web server and transmitting pa>Tnent information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the payment information and receive payment. For example, the merchant may use a 
secure telephone line or network link to contact the credit card issuer before accepting the 
customer's order. Eventually, the merchant and credit card issuer settle pa>Tnent and the 
merchant deli\'ers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventor}^ and pa>Tnent database and a payment acceptance and verification system. For 
example, the merchant must establish and mamtam a database tracking sales, delivery, and 
pa\mient information and product inventories in order to suppon the electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 
difficulty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and pa\nnent mformation and implement the functionalirv' to venfy - 
the pa\TTienL These tasks can be extremely difficult if the merchant accepts payment using 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 
in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flav^s of 
each system can be exploited. 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 
convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above. 

Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Internet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 
and verifiably perform inventory, sales, and delivery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
transactions that allows a merchant to easily sell a mix of physical and intangible items and 
suppons sales, inventory, and deliver>^ tracking and a variety of pa>Tnent systems by having the 
merchant establish an account on a commerce server. The commerce server provides the 
merchant with inventor\% accounting, and order management systems. Furthermore, the 
commerce sen'er allows merchants to conduct electronic commerce with other merchants and 
vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
usin2 these web pages, the merchant establishes an account on the commerce ser\'er. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payTnent systems are allowed and 
wlien or how onen to bill the customer. 
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The commerce server preferably stores the information received from the merchant in 
an entry of a database. In one embodiment, the database entr>' categorizes the item as a hard ' 
good, soft good, or online good depending upon the deliver}^ options available for the item. 
The commerce server, in addition, provides the merchant with a '*payment button'' including a 
5 universal resource locator ("URL*') that points to the commerce sender and includes 

information allowing the commerce server to identify the database entry with which the 
payment button is associated. The merchant preferably publishes the pajmient button on the 
merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 

10 associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce server and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web ser\^er 
with the payment information necessarv' to complete the transaction. 

15 When the merchant's payment terms specify that payment is required, the commerce 

server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 

20 into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the delivery options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 

25 an item to be purchased by the customer, receiving payment information specifying a payment 
method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote pa>Tnent system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 

30 transactions in accordance with the present invention include instructions for storing item 
information received from the merchant, instructions for issuing the merchant a reference to 
the stored item information, instructions for receiving an electronic commerce transaction 
identifier from the customer containins the reference to the stored item information issued to 
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the merchant, instructions for accepting payment information from the customer, and 
instructions for conducting the electronic commerce transaction with a remote pa\TTient system. 

Brief Description of the Drawings 

FIGURE 1 is a high-level block diagram of an electronic commerce system according 
to an embodiment of the present invention; 

PTQI FRH is a hiuh-level block diagram, illustrating functional componf^nt?^ of a 
commerce ser\^er according to an embodiment of the present invention; 

FIGURJE 3 is a high-level block diagram of an entry m a database associated with the 
commerce server according to an embodiment of the present invention; 

FIGURE 4 is a rlow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary screen display of a web page seeking pa>anent 
information from a customer; and 

FIGURE 6 illustrates an exemplar^^ screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 
As used herein, the "Internet" refers to the global network of interconnected computer 
systems and the "World Wide Web" ("WWW'') refers to the global hypertext system using the 
Internet as its transpon mechanism. A "universal resource locator" ("URJL") is a reference to a 
piece of information or a sofrware function on a computer connected to the Internet. A ''web 
server" is a program that accepts requests for information framed according to the HyperText 
Transport Protocol ("HTTP"). "Web pages" are the information supplied by the web server m 
response to the requests. The Common Gateway Interface ("CGI") is the standard that 
describes how the web server accesses extemal programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supponing electronic commerce. In a non- 
Intemet-based system, the terms defined above also include the non-Intemet-based equivalents 
for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 accordmg 
to an embodiment of the present invention. Illustrated are a customer computer ( sometimes 
referred to as "'the customer") 110, a merchant web server (sometimes referred to as "the 
merchant") 1 12. and a commerce ser\^er ("CS") 114, all coupled to the intemei 1 16. In a 

4 
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typical embodiment, the customer computer 1 10 is a personal computer having, among other 
things, a processor, memon^ storage device, and monitor. The customer computer 1 10 is 
coupled to the Intemet 1 16 via a network connection 1 1 S. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 
5 modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR*^, preferably executes on the client computer and sends data from the client 
computer 110 to the merchant web server 112 via the network connection 118 and Intemet 
116. In another embodiment, the customer computer 1 10 is a palm-top device or personal 
10 digital system communicating via radio waves with the Intemet 1 16 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 1 1 0 except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 1 12 sells items, such as merchandise, 

15 information, intellectual property, and/or ser\qces via a web site hosted. on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available for purchase, allow the customer 1 10 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 
a database of information. 

20 As used herein, the terms "customer" and "merchant" depend upon the specific 

transaction being conducted. In a chain of commerce transactions, the ''customer" in a first 
transaction may be a ''merchant" in a second transaction. For example, the customer 1 10 may 
buy components of a product from several different vendors or merchants 1 12 using the 
electronic commerce system described herein and then, in turn, sell the combined product via 

25 the customer's own web site and the CS 114. 

The merchant's v^^eb site displays at least one ''payment button." A payment button is a 
graphic button, a region of a larger graphic, a text stnng, or another form of URL link which 
the customer 110 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Intemet-based 

30 electronic commerce system. In such an embodiment, the payment button is considered to be 
''pressed" whenever a customer 1 10 expresses a desire to purchase an item. As described 
below, the pa>Tnent button is pressed by the customer 1 10 when the customer 1 10 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment. ever>' type of item for sale on the merchant's web site has a separate payment 
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button. When a customer 1 10 wishes to purchase the product, the 1 1 0 customer presses the 
product's associated pa>Tnent button. Then, the customer 1 10 is preferably presented with a - 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 110 wishes to purchase. 

In another embodiment, the merchant web site has only one payment button or has only 
one payment burton for each class of items for sale. In this embodiment, the customer 110 is 

thp nrtvnip.nt himnn. For examole. 

plCiCldUi^ pi WCH-llLiw».a iLXi. UL j.xxw*.x«. w^^*^. — ^ J- ^ J J - - i. - 

the menu of choices may ask the customer 1 1 0 to identify a specific product or an attribute of a 
product, like color, that the customer 1 10 wishes to purchase. 

Every payment button has an associated URL that points to information in the CS 114. 
Preferably, a database key that uniquely identifies the merchant 112 and/or item for sale is 
encoded within the URL. When the customer 110 presses the payment button, the customer 
1 10 IS redirected to a web page provided by the CS 1 14 and specific to the merchant 1 12 
and/or item. 

In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 
item that the customer 1 10 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and delivery options specified by the merchant 112. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 
transaction w^as successful. Accordingly, the merchant 112 is relieved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present invention. The CS 1 14 is preferably similar to the 
customer 1 1 0 and merchant 1 12 computers, except that the CS 1 14 has enough processing 
power and Internet 1 16 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or softv^^are modules within the CS 114. In one embodiment of the present invention, 
the functionalirv' of the CS 1 14 is provided by software apphcations executing on INTEL x86- 
or SUN MICROSYSTEMS SP.^C-compatible hardware under control of MICROSOFT 
WINDOWS NT or a derivative of the UNIX operating system, such as SOL.^^RIS 2.5.1. In 
another embodiment of the present invention, the fLinctionahrs^ of the CS 1 14 is provided by a 
distributed computing system as described below. 
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The remote payment system 222 is preferably a third-pany payment gateway or system. 
The gateway or system is preferably conjiected to a financial transaction nerwork, which, in " 
turn, r\TDically hnks to computers at banks and other financial institutions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
5 C\':BERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 1 1 6 or a dedicated secure 
link. Each pa>mient system has an applications programming interface (''APT'). By using the 
API, the CS 1 14 communicates with the payment system 222 and performs secure and 

10 verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 

15 110 electronic commerce transaction performed by the CS 114 may contact a remote pa>Tnent 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 

20 discrete entities, the CS 1 14 may be executed on a distributed computer system having a' 
plurality of engines, databases, and web servers working together the perform the functions 
described herein. For example, one embodiment of the CS 1 14 uses multiple transaction 
engines 210 and web ser\'ers 214 and a single distributed database 212, thereby providing 
scalability to the CS 1 14. The number of web servers 214 and transaction engines 210 depends 

25 on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 

30 Interface ("P^API") module 220 enabling communication between the CS 1 14 and the remote 
pa>mient systems 222 and merchants 223. The P.API module 220 abstracts the different .^Is 
of each payment system 222 and merchant 223 into a single, higher leveL PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment transactions with a pa\Tnent system 222 or merchant 223 by malcing 
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calls 10 the ?APL The PAPI abstracuon module 220 translates these calls into the specific .^I 
of the pa>anent system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 14 by merely creatmg a new P.API to payment system or merchant API mapping in the 
p A-PI abstraction module 220. 

The payment button store module ("PB store") 224, in combination with the web sender 
214, allows a merchant 112 to obtain a payment burton. The web server 214 is preferably an 
industo" standard web server such as the NETSCAPE ENTERPRISE SERVER or the 
APACHE web server. The web server 214 provides secure communication with the customer 
1 10 and preferably uses industry standard technologies including HyperText Markup Language 
(^'HTMU'), and HTTP to deliver information to the customer 110. In addition, the web ser\^er 
preferably uses industry standard encryption techniques, mcluding secure HTTP ('^S-HTTP") 
and the secure sockets layer (*'SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user caimot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase pa>mient buttons and add product 
descriptions, merchant configurations, and other information to the database 212. In a 
preferred embodiment of the present invention, the merchant 112 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 112 actions 
on the web server 214 and creates the appropriate entnes in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 
payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a pa>Tnent button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionahty 
described herein. 

The merchant registration form 226 allows the merchant i 12 to input information 
identifymg the merchant 1 12 and mcludes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is venrled. the merchant 1 12 is preferably issued 
a ioginy'password pair and an account with the CS 1 14 through which the merchant 1 12 can 
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access the pajTnent button generation fomi and maintain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a pajonem button with which the merchant 
1 12 can pay a renewal fee. 

The pa\anent button generanon form 230 allows the merchant 1 12 to enter item 
5 description data, such as item names and descriptions, prices, t^^Des, and deHver>' options, and 
pa\Tnent processing rules, such as supponed credit cards, payment systems, and currencies. In 
addition, the pa>Tnent processing rules may rank the payment systems in order of preference, 
describe when pa\Tnent is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quandty or duration of an item available for a cenain price. In one 
10 embodiment of the present invention, the merchant 1 12 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

WhQu entry of this data is completed, the payment button generation form 230 sends 
the data to the transaction engme 210, which stores the information in the database 212 at a 

15 location specified by a key. The transaction engine 210 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the pa\Tnent button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 112. The 
payment button has an associated URL that specifies the key. Accordingly, little or no 

20 engineering effort is required to maintain each merchant configuration on the CS 114. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, pa>Tnent buttons may be 

25 "branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the ORACLE 7 database to implement the functionality described 
herein. The database 212 stores item descriptions, pa^anent processing rules, and other 
information necessary to complete a payment transaction on behalf of a merchant 112, This 

30 merchant information is preferably accessed in the database by using a key assigned to each 

merchant 1 12 and/or item for sale. The database 212 is also used as a repository' of transaction 
information mciuding authorization logs, payment status and completion records, and other 
information required by the merchant 1 12 and the CS 114. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primary entry 310 linked to at least one 
of three types of item entnes 312, 314. 316. The primary entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 310 is typically 
accessed either when the merchant 1 12 provides the key while using the PB store web site or 
when the customer 110 uses the URL provided by a payment button to purchase the item 
identified in the database entr}' 310. 

The primary entry 310 contains a field 318 stonng the payment processing rules for the 
item as specified by the merchant 112 through the PB store. The primary entry 310 also 
contains a field 320 holding item t^^e information as specified by the merchant 1 12. The item 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312, 314, 316 describing delivery options for the item. 

The available deliver,' options for an item depend upon the t>'pe of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing delivery options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
delivering the hard item to the customer 110. 

A soft item, in contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 1 10. Accordingly, the entry 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to download the purchased soft item to the customer's 1 10 computer system. 

An online item is typically access to an online service or other software executing 
remotely from the customer 1 10. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entr>' 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 110 to access the online 
Item. For example, the options 326 may provide instructions for initiating a telnet session with 
an electronic database for a limited duration of time. 

FIG. 4 is a flow diagram illustrating the interactions ber^veen the customer 110^ 
nv-rchant 112. CS 1 1 4, database 212 and a paNTOent system 222 when completing a paATTieni 

10 
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transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to the bottom and horizonral lines represent 
communications between the various entities. FIG. 4 illustrates only major interactions 
between the entities and does not represent every interacdon. In addition, FIG. 4 illustrates a 
5 simple case of the present invention wherein the merchant's 112 payment processing rules 
specify that the payment transaction should be processed at the time the customer's 1 10 order 
is received. 

Initially, the customer 1 10 is browsing the merchant's web site and decides to purchase 
an Item by pressing 410 the associated payment button. In response to the press, the 

10 merchant's web server 112 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's browser fetches 414 
the referenced page from the CS 114. 

The CS 1 14 parses the URL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 110 wishes to purchase. Using this key, the CS 

15 114 accesses 416 the database 212 and dynamically generates a web page indicating the 
attributes and payment options available for the item as defmed by the merchant 112. In 
addition, the CS 1 1 4 preferably determines the language utilized by the customer 1 1 0 and 
currencies supported by the merchant 112 and modifies the web page accordingly. This 
generated web page is sent 418 to the customer 110. FIG. 5 illustrates an exemplary screen 

20 display 500 of the web page seeking pa>Tnent information from the customer 1 10. 

The customer selects the desired item attributes and payment service, enters any 
necessar>^ payment information, such as a credit card or account number, and transmits 420 
these data to the CS 114. The CS 1 14 stores 422 the received data m the database 212 and 
contacts the selected payment system ,222. As described above, the CS 1 14 preferably uses the 

25 PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API' 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
communications with the payment system 222, customer 1 1 0, and merchant 1 12 in the 
database 212. Therefore, the database 212 can be used to reconstruct transacdon histories in 
order to provide error tracking and accounting services. If the payment system 222 rejects the 

30 transaction, the CS 1 14 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG. 4). 

If the pavTOcnt system 222 approves the transacdon, the CS dynamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 110. This page preferably contains a receipt or confirmanon number generated by 
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the CS 1 14. In a preferred embodiment of the present mvention. the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entrs' holding the 
transaction information and can be used later by the merchant 1 12 and customer 1 10 to confinn 
payment, to query the CS 1 14 for pa>mient status information, and to use the CS 1 14 to query 
the pa\anent system for account status information. The web page also preferably contains any 
otner iniormaLiun icquucu uy luc; iiiuioAicmt 1 1-, cluv^ a. xiiiav ^ w^^*-..-^*.-— — 
merchant's web site 1 12. FIG. 6 illustrates an exemplary screen display 600 of an order 
confirmation web page. 

The CS 1 14 also notifies 428 the merchant 1 12 that pa>Tnent was accepted and provides 
the same receipt or confirmation number as was provided to the customer 110. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer i 10 and merchant 112 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the comlrmation web page on the merchant's 
web site. Preferably, this web page provides the customer 110 with additional information 
about the purchase or any other information which the merchant 1 12 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 1 12 opens an account on the CS 1 14 and suppUes 
information about items sold by the merchant 112. The CS 1 14 stores this information in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 112 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 110, conducts the electronic commerce transaction with a remote payment system 
222. and notifies the customer 110 and merchant 1 12 of the result. 
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Claims 

I claim: 

1 . A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising; 
5 a database having an entr>^ including merchant information identifying an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 

system for performing an electronic commerce transaction, the transaction 
engine comprising: 

10 a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entry in the database; 
a second module for accepting payment information from the customer, the 

pa>Tnent information identifying the remote payment system; and 
15 a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1, wherein the transaction engine further 
comprises: 

20 a founh module for notifying the remote merchant and the customer of a result of 

the electronic commerce transaction. 

3. The computer system of claim 1, further comprising: 

a web serv^er in communication with the transaction engine for communicating with 
the remote merchant and customer; and 
25 a firewall between the web sender and the transaction engine for securing 

communications between the web sender and the transaction engine. 

4. The computer system of claim 3, wherem the transaction engine further 
compnses: 

a fifth module for dxmamically generating a web page from the entrs^ in the database 

30 and providing the web page to the customer via the web ser\^en the web 

page providing information about the item offered for sale by the remote 

13 
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merchant and facilitating collection of the payment information from the 
customer. 

5. The computer system of claim 3, wherein the computer system funher 
composes: 

a sixth module for accepting the merchant information identifying the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant information, and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1 , wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entr>^ in the 
database- 

7. The computer system of claim L wherein the database further comprises: 

an entry specifying payment processing mles defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1 , wherein there are a plurality of available 
remote payment systems and wherein the second module for accepting pavonent information 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1 , wherein the transaction engine is executed by 
a plurality of distributed computer systems. 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a resuh of the 
payment transaction. 

1 L The method of claim 10, further composing the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1 , wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

1 3. The method of claim 1 0, further compnsmg the step of: 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of: 

receiving payment processing mles specifying payment options available for 

purchasing the item; and 
receiving deliver}'^ options for the item. 

15. A computer- readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

instructions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

msiruciions for accepting pa\TOent mformation from the remote customer, the 
pa\Tnent information identifsang a remote payment system; and 
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instructions for conducting the electronic commerce transaction with the remote 

pa\TOent system usmg the payment information received from the remote - 
customer. 

16. The computer-readable medium of claim 15, wherein the instructions further 
comprise: 

fnrnmifv/ina the remote merchant and the remote customer of a result 
of the electronic commerce transaction. 

17. The computer-readable medium of claim 1 5, wherein the instructions for stonng 
item information received from the remote merchant comprise: 

instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 

instructions for receiving deliver}^ rules from the remote merchant specifying 
dehvery options for the electronic commerce transaction. 



16 
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METHOD AND SYSTEM FOR CONDUCTING 
ELECTRONIC COMMERCE TRANSACTIONS 

Cross-Reference to Related Application 

This application is a continuation-m-part of U.S. Provisional Application No. 
60/054,121, filed July 29, 1997. 

Background 

Field of the Invention 

This invention penains in general to electronic commerce and in particular to a method 
and system for conducting electronic pa>Tnent transactions via the Internet. 

Backgrol^^d of the Invention 

Electronic commerce conducied over the Internet has become increasingly imponant 
over the last decade. Online merchants offer goods and services for sale or rent including 
physical objects such as compact disks, books, and clothing, and intellectual property such as 
streaming music and movies and electronic books. Physical items may be delivered to the 
customer via the mail or a variety of other shipping options. Intellectual property, in contrast, 
may be delivered to the customer by allowing a download via the file transfer protocol 
("FTP"), providing the customer with an access key, establishing a telnet session, or through 
some other form of electronic deliver>'. 

T>T3ically, these goods and services are displayed on the merchant's web site and a 
prospective customer views, selects, and purchases the goods using web browsing software 
such as NETSC.^E NAVIGATOR^'. The customer usually pays for a product by establishing 
a secure connection with the merchant's web ser\'er and transmitting pavTnent information, 
such as a credit card number, to the merchant. The merchant then uses back-end processing to 
verify the pa>Tnent information and receive payment. For example, the merchant may use a 
secure telephone line or nerwork link to contact the credit card issuer before accepting the 
customer's order. Evenmally, the merchant and credit card issuer settle payment and the 
merchant deli\'ers the product or service to the customer. 

A difficulty with the above-described scenario is that each merchant must implement an 
inventors^ and payment database and a payment acceptance and veriilcation system. For 
example, the merchant must establish and maintain a database tracking sales, delivery, and 
payment information and product inventories in order to support the-electronic commerce 
system. There is significant cost and complexity in maintaining this database, including the 
difllculty of integrating it with legacy accounting and fulfillment systems and aggravated by 
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the scarcity of truly skilled personnel. In addition, the merchant must design web pages to 
securely accept the order and payment information and implement the functionality to venfS' 
the payment. These tasks can be extremely difficult if the merchant accepts payment usmg 
many different methods, such as credit cards and electronic fund transfers, or accepts payment 
5 in more than one currency. Moreover, having a large number of separate payment acceptance 
systems on the Internet provides a greater opportunity for fraud and abuse because the flaws of 

Although Internet-based electronic commerce clearinghouses have been developed to 
handle transactions from many different parties, these clearinghouses do not provide a 
10 convenient interface to the merchant. In addition, the merchant must still establish the 
payment, verification, and database systems described above- 
Accordingly, there is a need in the art for a method and system for conducting 
electronic commerce on the Intemet which reduces the amount of work that must be performed 
by the online merchant. Preferably, the method and system will allow the merchant to easily 
15 and verifiably perform inventor\\ sales, and dehvery tracking and transparently support 
different types of payments and currencies. 

Summary of the Invention 

The above needs are met by a method and system for conducting electronic commerce 
20 transactions that allows a merchant to easily sell a mix of physical and intangible items and 

supports sales. inventoHrS and delivery tracking and a variety of payment systems by having the 
merchant establish an account on a commerce server. The commerce ser%^er provides the 
merchant with mventory^ accounting, and order management systems. Furthermore, the 
commerce ser\'er allows merchants to conduct electronic commerce with other merchants and 
25 vendors. 

The commerce server includes a web server providing web pages to the merchant. By 
using these web pages, the merchant establishes an account on the commerce server. Then, the 
merchant provides the commerce server with information about an item sold by the merchant, 
such as a plane ticket, clothing, a book, a software product, or playing time with an online 
30 game. The merchant also provides the commerce server with other attributes of the item from 
which the customer may select, for example, the quantity or duration of an item. In addition, 
the merchant supplies payment processing rules defining the payment options that are 
acceptable to the merchant, such as which currencies and payment systems are allowed and 
when or how onen to bill the customer. 

-) 
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The commerce server preferably stores the informaiion received from the merchant in 
an entry of a database. In one embodiment, the database entry categorizes the item as a hard 
good, soft good, or onhne good depending upon the dehvery options available for the item. 
The commerce ser\'er, in addition, provides the merchant with a ''payment button" including a 
5 universal resource locator (''URL") that points to the commerce serv^er and includes 

information allowing the commerce server to identifS' the database entry w^ith which the 
payment button is associated. The merchant preferably publishes the payment button on the 
merchant's web site. 

The customer selects the payment button when the customer wishes to purchase the 

10 associated product. In response, the customer's computer is automatically directed to the web 
server managed by the commerce ser\'er and provided with the item information entered by the 
merchant. In addition, the customer is presented with the payment options allowed by the 
merchant's payment processing rules. Preferably, the customer then provides the web sender 
with the payment information necessary to complete the transaction. 

15 When the merchant's payment terms specify that pa\Tnent is required, the commerce 

server preferably identifies the remote payment system selected by the customer and contacts it 
to complete the electronic commerce transaction. Preferably, a module within the commerce 
server converts calls generated by the commerce server into the format used by the selected 
payment system. Likewise, the module converts responses received from the payment system 

20 into the format used by the commerce server. Then, the commerce server notifies the customer 
and the merchant of the result of the electronic commerce transaction and, if appropriate, 
delivers the item using one of the deliver>' options specified in the database. 

A method of conducting electronic commerce between a remote customer and a remote 
merchant in accordance with the present invention includes receiving information identifying 

25 an item to be purchased by the customer, receiving payment information specifying a pa>mient 
method to be used by the customer to purchase the item, conducting a payment transaction 
with a remote payment system specified by the payment information, and providing the 
customer and the merchant with the result of the payment transaction. 

Similarly, computer program instructions for conducting electronic commerce 

30 transactions in accordance with the present invention include instructions for storing item 

information received from the merchant, instructions for issuing the merchant a reference to 
the stored item mformation, instructions for receiving an electronic commerce transaction 
identifier from the customer containing the reference to the stored item information issued to 
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the merchant, instructions for accepting pa\qnem informanon from the customer, and 
instructions for conducting the electronic commerce transaction with a remote pa\TOent system. 

Brief Description of the Drawings 

FIGURE 1 is a high-level block diagram of an electronic commerce system according 
to an embodiment of the present invention; 

FIGURE 2 is a hieh-level block diagram illn.^trating functional components of a 
commerce server according to an embodiment of the present invention; 

FIGURE 3 is a high-level block diagram of an entry in a database associated with the 
commerce server according to an embodiment of the present invention; 

FIGURE 4 is a flow diagram illustrating the interactions between the customer, 
merchant, commerce server, and payment system when completing a payment transaction 
according to an embodiment of the present invention; and 

FIGURE 5 illustrates an exemplary^ screen display of a web page seeking payment 
information from a customer; and 

FIGURE 6 illustrates an exemplar}' screen display of an order confirmation web page. 

Detailed Description of the Preferred Embodiment 

As used herein, the "Internet" refers to the global network of interconnected computer 
systems and the "World Wide Web" ("WWW") refers to the global hypertext system using the 
Internet as its transpon mechanism. A "universal resource locator" ("URL") is a reference to a 
piece of information or a softv-^are function on a computer connected to the Internet. A "web 
ser\'er" is a program that accepts requests for information framed according to the HyperText 
Iransport Protocol ("HTTP"). "Web pages" are the information supplied by the web ser%'er in 
response to the requests. The Common Gateway Interface ("CGI") is the standard that 
describes how the web server accesses external programs, usually called "CGI programs" or 
"CGI scripts," called by a web page. Of course, the present invention is not limited to the 
Internet and may be used with any digital network supporting electronic commerce. In a non- 
Intemet-based system, the terms defined above also include the non-Intemet-based equivalents 
for communicating between the various entities described herein. 

FIG. 1 is a high-level block diagram of an electronic commerce system 100 according 
to an embodiment of the present mvention. Illustrated are a customer computer (sometimes 
referred to as "the customer") 110, a merchant web ser\'er (sometimes referred to as "the 
merchant'! 112, and a commerce sender ("CS") 1 14, all coupled to the Internet 1 16. In a 

4 
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typical embodiment, the customer computer 1 1 0 is a personal computer having, among other 
things, a processor, memory, storage device, and monitor. The customer computer 1 10 is 
coupled to the Internet 1 1 6 via a network connection 1 1 S. The network connection may be, for 
example, a modem coupled to an analog telephone line, a digital subscriber line, a cable 
5 modem utilizing bandwidth on a cable television coaxial cable, a high speed digital line, or any 
other communications medium. Web browsing software, such as NETSCAPE 
NAVIGATOR®, preferably executes on the client computer and sends data from the client 
computer 1 1 0 to the merchant web ser\'er 1 12 via the network connection 118 and Internet 
116. In another embodiment, the customer computer 1 10 is a palm-top device or personal 
10 digital system communicating via radio waves with the Internet 1 16 or another electronic 
commerce system. 

The merchant web server 1 12 is preferably similar to the customer computer 1 lO except 
that it is has the processing power and communications 1 16 bandwidth to handle multiple 
simultaneous customer transactions. The merchant 1 12 sells items, such as merchandise, 

15 information, intellectual property, and/or ser\nces via a web site hosted on the merchant web 
server 1 12. The merchant's 1 12 web site may, for example, display a catalog of software 
available for purchase, allow the customer 1 10 to view flight schedules and purchase a plane 
ticket, or allow the customer 1 10 to play an online game, download a book or music, or access 
a database of information. 

20 As used herein, the terms "customer" and "^merchant" depend upon the specific 

transaction being conducted. In a chain of commerce transactions, the "customer'' in a first 
transaction may be a ^'merchant" in a second transaction. For example, the customer 1 10 may 
buy components of a product from several different vendors or merchants 1 12 using the 
electronic commerce system described herem and then, in turn, sell the combined product via 

25 the customer's own web site and the CS 114. 

The merchant's web site displays at least one "payment button." A payment button is a 
graphic button, a region of a larger graphic, a text string, or another form of URL link which 
the customer 1 10 may "press" by selecting it with a mouse, physical button, or other input 
device. In another embodiment, the payment button may be utilized on a non-Intemet-based 

30 electronic commerce system. In such an embodiment, the payment button is considered to be 
''pressed" whenever a customer 1 10 expresses a desire to purchase an item. As described 
below, the payment button is pressed by the customer 1 10 when the customer 110 wishes to 
purchase and pay for an item displayed for sale on the merchant's web site. In a preferred 
embodiment, e\'er\^ type of item for sale on the merchani's web site has a separate payment 
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button. When a customer 1 1 0 wishes to purchase the product, the 1 1 0 customer presses the 
product's associated pa\Tnent button. Then, the customer 1 1 0 is preferably presented with a 
menu allowing the customer 1 10 to specify attributes, such as quantity or duration, of the items 
that the customer 1 10 wishes to purchase. 
5 In another embodiment, the merchant web site has only one pa\Tnent buuon or has only 
one payment button for each class of items for sale. In this embodiment, the customer 1 10 is 
— r^^^t-^A -.-.rifU ^ ^ar^^•^ o Vi i c Q ft/^r T^r^a c CI Ti Q tVi p npA/mF^nt hnttnn For examnle. 

plCic:iciUi_)' ^ji uo*wiiLo»a v*iLxi ti. wi.A^iww^ ^^^w^ ^ — I--- - 

the menu of choices may ask the customer 1 10 to identify a specific product or an attribute of a 
product, like color, that the customer 1 10 wishes to purchase. 
10 Every payment button has an associated URL that points to information in the CS 1 14. 

Preferably, a database key that uniquely identifies the merchant 112 andy'or item, for sale is 
encoded within the URL. When the customer 1 10 presses the payment burton, the customer 
1 1 0 IS redirected to a web page provided by the CS 1 14 and specific to the merchant 1 12 
and/or item. 

15 In one embodiment, the CS 1 14 queries the customer for the quantity or duration of the 

item that the customer 1 10 wishes to purchase and payment information. The CS 1 14 receives 
the customer's responses and conducts the electronic commerce transaction according to 
payment processing rules and dehvery options specified by the merchant 1 12. The CS 1 14 
records the transaction in its database and notifies the customer and merchant whether the 
20 transaction was successful. Accordingly, the merchant 1 1 2 is reheved of the responsibility of 
conducting the electronic commerce transaction with the customer 110. 

FIG. 2 is a high-level block diagram illustrating functional components of the CS 114 
and also illustrating a remote payment system 222 and a remote merchant 223 according to a 
preferred embodiment of the present mvention. The CS 1 14 is preferably similar to the 
25 customer 1 10 and merchant 1 12 computers, except that the CS 1 14 has enough processing 

power and Internet 116 bandwidth to support many simultaneous payment button transactions 
as described herein. The functionality of the CS 1 14 described herein may be performed by 
hardware or software modules within the CS 1 14. In one embodiment of the present invention, 
the functionality of the CS 114 is provided by software applications executing on INTEL x86- 
30 or SUN MICROSYSTEMS SPARC-compatible hardware under control of MICROSOFT 
WINDOWS NT or a denvative of the UNIX operating system, such as SOLARIS 2.5.1. In 
another embodiment of the present invention, the functionality of the CS 1 14 is provided by a 
distributed computing system as described below. 
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The remote payment system 222 is preferably a third-party pa\anent gateway or system. 
The gateway or system is preferably connected to a financial transaction network, which, in 
turn, ti^Dically links to computers at banks and other financial institufions for approval and 
settlement of electronic commerce transactions. Typical gateways or systems may include 
CYBERCASH, e-CASH, MONDEX, or SET. While only one payment system 222 is 
illustrated in FIG. 2, the CS 1 14 may be in communication with many different remote 
payment systems 222, either through a secure link on the Internet 116 or a dedicated secure 
link. Each payment system has an applications programming interface C^API"). By usmg the 
API, the CS 114 communicates with the payment system 222 and performs secure and 
verifiable payment transactions. 

The remote merchant 223 is preferably a merchant selling items via a web site as 
described above. The remote merchant 223 may have an account on the CS 1 14 or the 
merchant 223 may have an interface for selling items similar to the remote payment system 
222. In general, the remote merchant 223 is included in FIG. 2 to illustrate that the customer's 
1 10 electronic commerce transaction performed by the CS 114 may contact a remote pavrnem 
system 222 and/or a remote merchant 223. 

The CS 1 14 includes a payment button transaction engine 210 which is coupled to a 
database 212 and a web server 214. A firewall 216 preferably sits between the web server 216 
and the transaction engine 210. While these functional components are illustrated in FIG. 2 as 
discrete entities, the CS 1 14 may be executed on a distributed computer system having a 
plurality of engines, databases, and web servers working together the perform the fimctions 
described herein. For example, one embodiment of the CS 1 14 uses multiple transaction 
engines 210 and web serv^ers 214 and a single distnbuted database 212, thereby providing 
scalability to the CS 1 14. The number of web serveis 214 and transaction engines 210 depends 
on the actual system load and the desire to achieve better performance through balancing the 
transaction load across the system. 

The payment button transaction engine 210 includes a rules module 218 that controls 
the interactions and flows of information necessary to complete^a payment transaction. In 
addition, the transaction engine 210 preferably includes a Payment Application Programming 
Interface C'P.API") module 220 enabling communication between the CS 1 14 and the remote 
pa\Tnent systems 222 and merchants 223, The PAPl module 220 abstracts the different APIs 
of each pa>mient system 222 and merchant 223 into a single, higher level, PAPI that can 
interface with each of the payment systems 222 and merchants 223. The transaction engine 
210 performs payment rransaciions with a pa\Tnent system 222 or merchant 223 by making 
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calls lo the PAPl. The PAPI abstraction module 220 translates these calls into the specific .\PI 
of the pa\TBent system 222 or merchant 223 being used for that transaction. The PAPI 
abstraction module 220 also translates data received from the payment system 222 or merchant 
223 into the format utilized by the transaction engine 210. Accordingly, the PAPI abstraction 
module 220 allows support for new payment systems 222 and merchants 223 to be added to the 
CS 1 1 4 by merely creating a new^ PAPI to payment system or merchant API mapping in the 

D A t>T ^U^-+^0/^^-^i-^T^ T-t-lQ^Vllg 220. 

The payment button store module ("PB store") 224, in combination with the web server 
214. allows a merchant 1 12 to obtain a payment button. The web server 214 is preferably an 
industry standard web serx^er such as the NETSCAPE ENTERPRISE SERVER or the 
APACHE web server. The web server 214 provides secure communication with the customer 
110 and preferably uses industry standard technologies including HyperText Markup Language 
("HTML"), and HTTP to deliver information to the customer 110. In addition, the web ser\'er 
preferably uses industry standard encrNT^tion techniques, including secure HTTP C'S-HTTP") 
and the secure sockets layer ("SSL"), to ensure that communications with the customer 1 10 are 
private. The firewall 216 allows only authorized communications between the web server 214 
and the transaction engine 210 and ensures that a malicious user cannot access or corrupt the 
transaction engine 210. 

The PB store 224 allows the merchant to purchase payment buttons and add product 
descriptions, merchant configurations, and other information to the database 212. In a 
preferred embodiment of the present invention, the merchant 112 accesses the PB store through 
a web site on the web server 214. The PB store module 224 captures the merchant 1 12 actions 
on the web ser\'er 214 and creates the appropriate entries in the database 212. 

In one embodiment of the present invention, the PB store web site describes the 
payment button mechanism, the services offered by the payment button vendor, and the costs 
of the services. In addition, the web site preferably has a merchant registration form 226 for 
registering new merchants, a merchant renewal form 228 for renewing merchant registrations, 
and a payment button generation form 230 for issuing payment buttons to registered 
merchants. The forms preferably include CGI programs for performing the functionality 
described herein. 

The merchant registration form 226 allows the merchant 1 12 to input information 
identifying the merchant 1 12 and includes a payment button with which the merchant 1 12 can 
pay a registration fee. After the fee payment is verified, the merchant 1 12 is preferably issued 
a login/password pair and an account with the CS 114 through which the merchant 112 can 
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access the payment button generation form and mainrain the merchant's account. Similarly, 
the merchant renewal form 228 preferably includes a payment button with which the merchant 
1 12 can pay a renewal fee. 

The pajonent button generation form 230 allows the merchant 112 to enter item 
description data, such as item names and descriptions, prices, tN^Des, and delivery options, and 
payment processing rules, such as supported credit cards, payment systems, and currencies. In 
addition, thepav-ment processing rules may rank the payment systems in order of preference, 
describe when payment is required (e.g., the merchant may require billing after 90 days), 
and/or describe the quantity or duration of an item available for a cenain price. In one 
embodiment of the present invention, the merchant 1 12 enters the item description data and 
payment processing rules by uploading a file to web site having the information in a 
standardized format. 

When enirv' of this data is completed, the payment button generation form 230 sends 
the data to the transaction engine 210, which stores the information in the database 212 at a 
location specified by a key. The transaction engine 210 passes the key back to the PB store 
web site, which provides the merchant with a payment button download page displaying the 
results of the paNTnent button generation transaction. If the transaction was successful, the 
payment button download page includes the payment button issued to the merchant 1 12. The 
pa>'ment button has an associated URL that specifies the key. Accordingly, little or no 
engineering effort is required to maintain each merchant configuration on the CS 1 14. 

In one embodiment of the present invention, there are multiple PB store web sites 
communicating with the database 212 through the transaction engine 210. When a payment 
button is created, the transaction engine 210 creates a field in the database 212 entry specifying 
the PB store that generated the payment button. Accordingly, payment buttons may be 
"branded" among different payment button vendors. 

The database 212 is preferably a robust relational database. A preferred embodiment of 
the present invention uses the OFL^CLE 7 database to implement the functionalit>' described 
herein. The database 212 stores item descriptions, paj-ment processing rules, and other 
information necessar\' to complete a payment transaction on behalf of a merchant 1 12. This 
merchant informadon is preferably accessed in the database by using a key assigned to each 
merchant 112 and/or item for sale. The database 212 is also used as a repository of transacdon 
information including authorization logs, pa>'ment status and completion records, and other 
information required by the merchant 1 12 and the CS 114. 
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FIG. 3 is a high-level block diagram of functional components within the database 212. 
Illustrated therein are a database entry 300 including a primar\^ entry 310 linked to at least one 
of three types of item entnes 312, 314, 316. The primar>^ entry 310 is the entry identified by 
the key provided to the merchant 112. Accordingly, the primary entry 310i5 typically 
accessed either when the merchant 112 provides the key while using the PB store web site or 
when the customer 110 uses the URL provided by a payment button to purchase the item 

- 1 .-f-.j :„ -i-T , rj 1 n 

lUCIlLlilCU iii LliC ucLLauu-ok- ^iiLij/ 

The pnmar>^ entry 310 contains a field 3 1 8 storing the payment processing rules for the 
Item as specified by the merchant 112 through the PB store. The pnmary entry 310 also 
contains a field 320 holding item type infomiation as specified by the merchant 1 12. The item 
type information preferably describes the item attributes input by the merchant 112. In 
addition, the item type information field 320 preferably contains at least one link to another 
database entry 312, 314, 316 describing delivery options for the item. 

The available dehvery options for an item depend upon the type of item. FIG. 3 
illustrates three database entries 312, 314, 316 describing deliver>' options for hard, soft, and 
online items. However, an embodiment of the present invention may have many different 
types of items and corresponding delivery options. A hard item is typically a manufactured 
physical product such as clothing, a book, or a machine part. Accordingly, the entry 312 
holding delivery options 322 may list various shipping methods and companies available for 
delivering the hard item to the customer 1 1 0. 

A soft item, m contrast, is typically intangible intellectual property such as music, 
electronic books, or software. For example, the soft item may be a streaming music file that 
can be played by the customer 110. Accordingly, the entr>^ 314 holding delivery options 324 
may list a URL or electronic key that can be provided to the customer to effectuate the 
purchase. For example, the options 324 may provide instructions for initiating an FTP session 
to dov^load the purchased soft item to the customer's 1 10 computer system. 

An online item is typically access to an onHne ser%ace or other software executing 
remotely fi-om the customer 110. For example, the online item may be access to an electronic 
database of information or an online game. Accordingly, the entry 316 holding delivery 
options 326 preferably includes instructions for allowing the customer 1 10 to access the online 
item. For example, the options 326 may provide instructions for initiatmg a telnet session witl 
an electronic database for a limited duration of time. 

FIG- 4 is a flow diagram illustrating the interactions beuveen the customer 110, 
merchant 112. CS 114, database 212 and a pa\anent system 222 when completing apa>Tnent 
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transaction according to a preferred embodiment of the present invention. In the flow diagram, 
time flows from the top of the diagram to the bottom and horizontal lines represent 
communications between the various entities. FIG. 4 illustrates only major interactions 
between the entities and does not represent evers^ interaction. In addition, FIG. 4 illustrates a 
5 simple case of the present invention wherem the merchant's 112 payment processmg rules 
specify that the payment transaction should be processed at the time the customer's 1 10 order 
is received. 

Initially, the customer 1 10 is browsing the merchant *s web site and decides to purchase 
an item by pressing 410 the associated payment button. In response to the press, the 

10 merchant's web ser\'er 1 12 redirects 412 the customer's browser to the location on the CS 1 14 
specified by the URL associated with the payment button. The customer's browser fetches 414 
the referenced page from the CS 1 14. 

The CS 1 14 parses" the URL received from the customer 1 10 for the database 212 key 
corresponding to the item that the customer 1 10 wishes to purchase. Using this key, the CS 

15 114 accesses 416 the database 212 and d>Tiamically generates a web page indicating the 
attributes and payment options available for the item as defined by the merchant 112. In 
addition, the CS 1 14 preferably determines the language utilized by the customer 110 and 
currencies supported by the merchant 1 12 and modifies the w^eb page accordingly. This 
generated web page is sent 41 8 to the customer 1 1 0, FIG. 5 illustrates an exemplar^' screen 

20 display 500 of the web page seeking payment information from the customer 1 10. 

The customer selects the desired item attributes and payment service, enters any 
necessary payment information, such as a credit card or account number, and transmits 420 
these data to the CS 114. The CS 1 14 stores 422 the received data in the database 212 and 
contacts the selected payment system 222. As described above, the CS 1 14 preferably uses the. 

25 PAPI module 220 to translate transaction calls made by the transaction engine 210 into the API 
of the selected payment system 222. The CS 1 14 preferably stores 426 records of all 
communications with the payment system 222, customer 1 10, and merchant 1 12 in the 
database 212. Therefore, the database 212 can be used to reconstruct transaction histories in 
order to provide error tracking and accounting services. If the payment system 222 rejects the 

30 transaction, the CS 1 14 publishes a web page to the customer indicating this result and 
presenting alternative payment methods, if any (this interaction is not shown in FIG. 4). 

If the payment system 222 approves the transaction, the CS d\TLamically generates a 
web page containing payment status information and publishes 428 this information to the 
customer 1 10. This page preferably contains a receipt or confimiation number generated by 

11 
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the CS 1 14. In a preferred embodiment of the present mvention, the confirmation number is a 
unique number encoding transaction, session, and merchant identifications and a time and date 
stamp. This confirmation number is preferably a key to a database entry holding the 
transaction information and can be used later by the merchant 1 12 and customer 110 to confirm 
5 payment, to quer>^ the CS 1 1 4 for payment status information, and to use the CS 1 14 to query 
the payment system for account status information. The web page also preferably contains any 

H o linV tn ^ rnnfirmarinn nase on the 
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merchant's web site 112. FIG. 6 illustrates an exemplar}' screen display 600 of an order 
confirmation web page. 

10 The CS 1 14 also notifies 428 the merchant 1 12 that payment was accepted and provides 

the same receipt or confirmation number as was provided to the customer 110. In one 
embodiment, this notification is performed via a secure electronic mail message. Accordingly, 
both the customer 1 10 and merchant 1 12 are notified that the purchase was made. 

Finally, the customer 110 fetches 430 the confirmation web page on the merchant's 
15 web site. Preferably, this web page provides the customer 1 10 with additional information 
about the purchase or any other information which the merchant 1 12 desires to provide. 

In summary, the present invention is a system, method, and computer program 
instructions for conducting electronic commerce transactions via the Internet or any electronic 
communication system. The merchant 112 opens an account on the CS 1 14 and suppUes 
20 information about items sold by the merchant 112. The CS 1 14 stores this mforaiation in a 
database 212 entry and issues the merchant 112 a URL containing the key to database entry. 
The merchant 1 12 supplies this URL to customers wishing to purchase an item, causing a 
customer 1 10 to be connected to the CS 1 14. The CS 1 14 collects payment information from 
the customer 110, conducts the electronic commerce transaction with a remote payment system 
25 222, and notifies the customer 110 and merchant 1 12 of the result. 
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Claims 

1 claim: 

1 . A computer system for supporting electronic commerce transactions between a 
customer and a remote merchant, the computer system comprising: 

a database having an entry' including merchant mformation ideniifymg an item 

offered for sale by the remote merchant; and 
a transaction engine in communication with the database and a remote payment 

system for performing an electronic commerce transaction, the transaction 
engine comprising: 

a first module for receiving an electronic commerce transaction identifier 

from the customer, the electronic commerce transaction identifier 

specifying the entr>' in the database; 
a second module for accepting pa\Tnent information from the customer, the 

payment information identifying the remote payment system; and 
a third module for performing the electronic commerce transaction with the 

remote payment system using the payment information received 

from the customer. 

2. The computer system of claim 1, wherein the transaction engine further 
comprises: 

a fourth module for notifying the remote merchant and the customer of a result of 
the electronic commerce transaction. 

3. The computer system of claim 1, further comprising: 

a web ser\'er in communication with the transaction engine for communicating with 

the remote merchant and customer; and 
a firewall between the web serv^er and the transaction engine for securing 

communications between the web sender and the transaction engine. 

4. The computer system of claim 3, wherein the transaction engme further 
comprises: 

a fifth module for d>mamically generating a web page from the entr>^ in the database 

and providing the web page to the customer via the web server, the web 

page providing information about the item offered for sale by the remote 
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merchant and facilitating collection of the payment infomiation from the 
customer. 

5. The computer system of claim 3, wherein the computer system further 
comprises: 

a sixth module for accepting the merchant information identifymg the item offered 
for sale by the remote merchant via the web server, creating the database 
entry for holding the merchant informatiom and providing the remote 
merchant with a reference to the database entry. 

6. The computer system of claim 1, wherein the electronic commerce transaction 
identifier is a URL identifying the computer system and including a key to the entry in the 
database. 

7- The computer system of claim L wherein the database further comprises: 

an entry specifying payment processing rules defined by the remote merchant; and 
an entry specifying delivery options for the item offered for sale by the remote 
merchant. 

8. The computer system of claim 1, wherein there are a plurality of available 
remote payment systems and v/herein the second module for accepting payment infomiation 
from the customer accepts payment information identifying one of the available remote 
payment systems. 

9. The computer system of claim 1, wherein the transaction engine is executed by 
a plurality of distributed computer systems, 

10. A method of conducting electronic commerce between a remote customer and a 
remote merchant, the method comprising the steps of: 

receiving information identifying an item to be purchased by the remote customer; 
receiving payment information specifying a payment method to be used by the 

remote customer to purchase the item; 
conducting a payment transaction with a remote payment system specified by the 

payment information; and 
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providing the remote customer and the remote merchant with a result of the 
pa>TTient transaction. 

1 1 . The method of claim ] 0, further comprising the steps of: 

receiving information about the item to be purchased from the remote merchant; 
storing the information about the item to be purchased at a specified location; and 
providing the remote merchant with a reference to the specified location. 

12. The method of claim 1 1, wherein the remote merchant provides the reference to 
the specified location to the remote customer responsive to the remote customer desiring to 
purchase the item. 

13. The method of claim 10, further compnsing the step of 

providing the remote customer with a list of item attributes from which the 
customer can select. 

14. The method of claim 10, wherein the step of receiving information identifying 
the item to be purchased by the remote customer comprises the steps of 

receiving payment processing rules specifying payment options available for 

purchasing the item; and 
receiving delivery options for the item. 

15. A computer-readable medium having computer instructions encoded thereon for 
conducting electronic commerce transactions between a remote merchant and a remote 
customer, the computer instructions comprising: 

instructions for storing item information received from the remote merchant; 
instructions for issuing the remote merchant a reference to the stored item 
information; 

insn-uctions for receiving an electronic commerce transaction identifier from the 
remote customer containing the reference to the stored item information 
issued to the remote merchant; 

instructions for accepting payment information from the remote customer, the 
pa\Tnent information identifying a remote pa\Tnent system; and 
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instructions for conducting the electronic commerce transaction with the remote 
payment system using the payment information received from the remote 
customer. 

1 6. The computer-readable medium of claim 15, wherein the instructions further 
comprise: 

instructions for notifying the remote merchant and the remote customer of a result 
' of the electronic commerce transaction. 

17. The computer-readable medium of claim 15, wherein the instmctions for storing 
item information received from the remote merchant comprise: 

instructions for receiving payment processing rules from the remote merchant 

specifying payment options for the electronic commerce transaction; and 

instructions for receiving delivery rules from the remote merchant specifying 
deliver>^ options for the electronic commerce transaction. 
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PAYMENT DETAILS 



PLEASE REVIEW THIS PAGE AND ENSURE IT IS CORRECT, 
BEFORE COMPLETING YOUR PAYMENT DETAILS. 



PRODUCTS ORDERED 



SKU QTY ITEMS 
2121 2 SPROCKET 



UNIT PRICE EXTENDED PRICE 
$8.99 $17.98 
SUBTOTAL; $17.98 
SHIPPING: $ 3.95 
TAX: $ 1.72 

TOTAL: $23.65 



BILLING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2; 
CITY: 
STATE: 
ZIP: 



SHIPPING ADDRESS 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



PAYMENT INFORMATION 



PAYMENT TYPE: MASTERCARD 

NAMEAS IT APPEARS ON CARD ♦ j 

NUMBER * ] — 

EXPIRATION DATE * I 1 / 1 



j MAKE CORRECTIONS ) 



PROCESS ORDER 
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RECEIPT 



--THANK YOU FOR YOUR ORDER - - 
RECEIPT NUMBER: 1587-8029-5 

/-NDAi oDDOLTirxQ nnftyiPAMV IMP. 
2243 E WISTENA WAY, BOSTON, MA 24248, USA 

EMAIL: INFO@SPROKETS.COM. WEB: HTTP//WWW.SPROKETS.COM 
I PRODUCTS ORDERED 



SKU QTY ITEMS 
2121 2 SPROCKET 



UNIT PRICE TOTAL PRICE 
S8.99 $17.98 
SUBTOTAL: $17.98 
SHIPPING; $ 3.95 
TAX: $ 1.72 

TOTAL: $23.65 



BILLING ADDRESS 



SHIPPING ADDRESS 



FIRST NAME: 
LAST NAME: 
COMPANY: 
ADDRESS 1: 
ADDRESS2: 
CITY: 
STATE: 
ZIP: 



JOE 

BLOGGS 

GLOBAL BAKING COMPANY 
2252 N. PETERS RD. 

SAN JOSE 
CA 

96025-5123 



□ 



PAYMENT INFORMATION 



PAYMENT TYPE: _ MASTERCARD 

YOUR CARD HAS BEEN CHARGEU: $23.65 



CUSTOMER INFORMATION 



WE AIM TO SHIP ITEMS WITHIN 10 DAYS 
THANK YOU FOR YOUR ORDER! 



RETURN TO SITE 



FIG. 6 
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